don't skip the "build platforms" job even when there are no platforms to build #283
Conversation
|
I'm holding up this change until runners can be more robust in handling cancelled jobs. |
|
changes effectively incorporated in #1703 |
Out of curiosity, does this mean that the runners now more robustly handle cancelled jobs? |
|
No, they still have problems with that 😞 But this PR is from.. oh man almost 1 year ago.. I don't want to hold up progress forever. Maybe the problems will be benign in practice, or maybe this will force me to come up with a solution quicker. |
You got my hopes up. Although it doesn't come up too frequently. Thanks for the reply. |
When there are no platforms to build for the platform cache, it conceptually makes sense to skip the platform building job matrix. But skipping a job in the middle of the graph like this causes some grief downstream: we needed to start doing things like
if: always() && needs.Build.result == 'success'for dependent jobs because the defaultsuccess()rule didn't like to see an ancestor skipped.But this
if: always()hack comes with a nasty side effect: it's impossible to cancel the workflow. Apparently a job withif: always()is not cancellable. This is particularly annoying when something like NP Tests fail and you have to wait until LR Tests finish before you can retry the workflow.So instead, the Build Platforms job will now inject a dummy entry in to its matrix when there are no platforms to build. This allows the job to still pass when it has no work to do and all dependent jobs don't need the
if: always()hack. Thus making the workflow cancellable.At some point, the discover & build jobs should be bundled in to a reusable workflow to encapsulate away some of the gory details.